Skip to main content

Pod Disruption Budget (PDB)

Overview​

A Pod Disruption Budget (PDB) is a resource in a Kubernetes cluster that limits the number of Pods that can be down simultaneously (or the number of Pods that must be maintained) to ensure application availability.

It is used to prevent services from becoming completely unavailable during Voluntary Disruptions, such as node upgrades or draining.

Why PDB is Needed​

In Kubernetes, there are two types of disruptions that cause Pods to stop:

  1. Involuntary Disruptions

    • Hardware failures
    • Kernel panics
    • Node network disconnection
    • Forced termination due to OOM (Out Of Memory)

  2. Voluntary Disruptions

    • Node draining by cluster administrators (kubectl drain)
    • Cluster upgrades
    • Node scaling down by autoscaling

PDB primarily works for 2. Voluntary Disruptions. When an administrator performs maintenance tasks, if a PDB is configured, Kubernetes can safely evict Pods while adhering to the application's availability requirements (e.g., minimum required number of Pods).

PDB Configuration Parameters​

PDB mainly uses one of the following two parameters to define limits:

1. minAvailable​

Specifies the number of Pods that must be maintained during a voluntary disruption.

  • Integer: Absolute number (e.g., 2)
  • Percentage: Percentage of replicas (e.g., 50%)

2. maxUnavailable​

Specifies the maximum number of Pods that can be unavailable simultaneously during a voluntary disruption.

  • Integer: Absolute number (e.g., 1)
  • Percentage: Percentage of replicas (e.g., 25%)
tip

Generally, it is recommended to use maxUnavailable for stateless web applications and minAvailable for stateful applications (such as databases) that require a quorum.

Configuration Examples​

Example 1: Always maintain at least 2 Pods (minAvailable)​

Ensures that at least 2 Pods are always running for a Deployment with 3 replicas.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Example 2: Allow only 1 Pod to be down at a time (maxUnavailable)​

Limits the number of Pods stopped at once to 1, even if the replica count varies. This is effective when you expect behavior similar to a rolling update during maintenance.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb-max-unavailable
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app

Default Settings in AKS​

The default behavior of PDBs in an AKS cluster is as follows:

User Workloads​

For applications deployed by users (such as Deployments and StatefulSets), no PDB is configured by default. If you do not explicitly create a PDB, all Pods on a node may be evicted simultaneously during a node upgrade or drain. This poses a risk of temporary service disruption, so configuring PDBs is strongly recommended for production environments.

System Components​

Some system components managed by AKS (resources in the kube-system namespace, etc.) have PDBs configured by default.

  • CoreDNS: Critical system Pods like coredns typically have a PDB set (e.g., minAvailable: 1) to ensure that cluster DNS resolution capabilities are maintained.
  • Konnectivity Agent: These are similarly protected to ensure availability.

Considerations in AKS​

When using Azure Kubernetes Service (AKS), PDB becomes important in the following scenarios:

  • AKS Cluster Upgrades: During node image updates or Kubernetes version upgrades, AKS drains and restarts nodes sequentially. Configuring a PDB prevents service downtime during this process.
  • Cluster Autoscaler: PDB is respected when node scale-in (deletion) occurs.

Caveats​

  1. Avoid PDB Conflicts: If you set minAvailable to the same value as the replica count (e.g., minAvailable: 3 for 3 replicas), no Pods can be stopped, blocking node draining or upgrades. Always leave room for at least one Pod to be stopped.
  2. Label Matching with Deployment: The PDB selector must exactly match the labels of the target Deployment or StatefulSet.
  3. Single Pod Configuration: For an application with 1 replica, setting maxUnavailable: 0 or minAvailable: 100% will prevent that Pod from being voluntarily stopped. If high availability is required, consider increasing the replica count to 2 or more first.

Summary​

Pod Disruption Budget is a crucial feature for balancing "system stability" and "operational flexibility (maintenance)" in Kubernetes operations. It is highly recommended to configure appropriate PDBs for critical workloads running in production environments.